개요

이 문서는 기본적인 디플로이먼트 사용법을 나열하는 문서이다.
이 문서를 통해 알 수 얻을 수 있는 것은 간단한 양식 작성법, 명령줄 조작법이다.
조작은 대체로 rollout을 통해서 이뤄진다.

디플로이먼트 만들기

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

kubectl로 정의된 양식을 어떻게 적용하는지는 저짝 문서에서 참고..

문서를 적용했을 때, 디플과 파드, 레플리카셋을 찍어보았다.
이름을 보면 알 수 있듯이 디플-레플-파드 순으로 무작위 네이밍이 된 것이 보인다.
구조에 대한 내용은 Deployment#동작 구조에서 참고하도록 하고, 여기에서는 명령줄에 나온 출력물을 보겠다.
디플로이먼트의 출력은 이렇다.

• NAME - 말그대로 디플로이먼트의 이름이다.
• READY - 현재 관리되는 레플에서 몇 개의 앱이 준비 상태인지 나타낸다.
• UP-TO-DATE - 원하는 상태로 업데이트된 앱 개수를 나타낸다.
• AVAILABLE - 이용가능한 앱 개수를 나타낸다.
  • 거의 READY와 비슷한데, 사용자가 준비 상태를 정의할 수 있는 READY가 더 쓸모 있는 정보인 듯.
• AGE - 말 그대로 언제부터 앱이 돌아가기 시작했는지를 나타낸다.

다음 레플리카셋의 출력은 이렇다.

• NAME - 말그대로 디플로이먼트의 이름이다.
• DESIRED - 원하는 상태로 업데이트 된 앱 개수를 나타낸다.
• CURRENT - 현재 돌아가는 앱 개수를 나타낸다.
• READY - 현재 관리되는 레플에서 몇 개의 앱이 준비 상태인지 나타낸다.
• AGE - 말 그대로 언제부터 앱이 돌아가기 시작했는지를 나타낸다.

둘이 비슷해서 헷갈리지만, 버전을 업데이트할 때 이 두 출력의 차이가 명백해질 것이다.

상태, 기록 확인

rollout status를 통해 현재 디플이 어떤 상태인지 볼 수 있다.

rollout history를 통해 여태의 변경 이력을 확인한다.
--revision 을 넣으면 특정 버전의 이력을 자세하게 확인하는 것도 가능하다.

디플로이먼트 업데이트

방법

디플로이먼트의 주 기능 중 하나인 버전 업데이트를 해보자.
방법은 여러가지가 있다.

set 이용

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1

문서에서는 디플로이먼트 객체를 직접 잡아서 수정하지만 이렇게 파일을 토대로 하는 것도 가능하다.
예시에서는 이미지에 해당하는 부분에 수정을 가했는데, 더 다양하게 수정을 가하려면 edit을 쓰는게 좋다.

edit 이용

이건 말그대로 파일로 수정하면 된다.

버전을 바꿨다.

레플리카셋이 각 버전을 나타낸다고 디플로이먼트에서 설명했듯이, 출력하면 각 버전에 해당하는 레플리카셋이 잡히고 있다.

셀렉터 업데이트

현재 쿠버네티스에서 공식으로 지원하는 디플로이먼트는 셀렉터 변경을 지원하지 않는다.

업데이트 방식

rollingUpdate

새로운 버전이 뜨고, 이전 버전이 삭제되는 과정이 출력된다.
이때 맨끝에 삭제된 파드가 2개밖에 되지 않는 것은 왜일까?
앞서 한 파드가 먼저 삭제됐기 때문이다.
디플로이먼트의 업데이트에 대해 퍼센티지 단위로 업데이트되는 양을 조절할 수 있다.

RollingUpdateStrategy:  25% max unavailable, 25% max surge

describe하며 나오는 이부분에서 이걸 확인할 수 있다.

업데이트가 되는 와중에도 이 디플로이먼트는 요구되는 상태에서 최소 25% 낮게 파드의 수를 줄일 수 있는 한편 최대 25퍼까지 파드의 수를 늘릴 수 있도록 되어 있다.
즉, 흔히 롤링 배포 방식을 사용한다는 것이다.

과정을 찍어보면 새 버전의 개수가 점차 늘어나고, 이전 버전의 개수가 점차 줄어드는 방식으로 동작하는 것이 확인된다.
이런 방식을 proportional scaling, 비례적 스케일링이라 부르는데 그렇게 대단한 개념은 아닌 듯.

디플로이먼트 롤백

이전 버전으로 돌리는 행위.
위에서 잠시 언급했지만, 파드의 템플릿이 변경되는 행위만이 버전으로 관리된다.
그 외의 부분, 가령 복제본 수를 바꾸는 행위에 대해서는 롤백이 불가능하다는 것을 의미한다.

존재하지 않는 이미지를 다운 받게 해서 에러가 난 상황.

상황을 잘 보면 여태 이야기한 것들이 전부 확인된다.
일단 이용가능한 상태인 전 버전들이 8개 떠 있다.
새 버전은 5개를 띄웠는데 전부 에러가 발생해서 추가적인 업데이트가 되지 않고 있다.
maxSurge가 25퍼이고 희망 상태가 10이므로 최대 13개까지만 파드가 띄워질 수 있어서 이 정도 선에서 시도되다가 ready 상태 최소 수치가 기준치를 충족하지 못해서 막혀버린 것이다.

rollout undo를 통해 직전 버전으로 다시 변경한다.
--to-revision옵션을 넣어서 내가 원하는 버전으로 롤백하는 것도 가능하다.
이 명령어의 동작은 이전 버전을 없애고 새로운 버전을 남긴다.
6버전은 순수히 undo를 통해 생겨났다.

디플로이먼트 스케일링

스케일링을 하는 방법도 하나의 업데이트가 아닐까, 버전으로 남는 게 좋지 않을까 잠깐 생각했는데, 스케일링은 너무 자주 일어날 동작이라 적절하지 않겠다는 생각이 들었다.
더구나 나중에 HPA라는 것을 통해 오토 스케일링을 할 거라 버전 관리를 할 필요도 없다.
아무튼 여기에서는 수동으로 스케일링 하는 방법을 본다.

scale을 이용해서 스케일링을 진행한다.
위에서처럼 edit을 활용하는 방법도 존재한다.

롤아웃 중단과 재개

위에서 롤백을 위해 존재하지 않는 이미지를 사용해봤는데, 롤백을 하면 이력이 남는다.
간단한 수정에도 일일히 이력이 남으면 좋지 않을 것이다.
이때 사용하는 게 pause로, 여러 수정사항을 한꺼번에 반영하게 할 수 있다.
별건 없고, 그냥 rollout pause를 하고 이후에 실컷 변경 다하면 rollout resume으로 풀어준다.

참고

• 문서
  • https://kubernetes.io/docs/concepts/workloads/controllers/deployment/